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METHOD AND SYSTEM FOR REQUESTING PRICES FOR 
ELECTRONIC TRADING OF FINANCIAL INSTRUMENTS 

CROSS-REFERENCE TO RELATED APPLICATION 

This application claims the benefit, under 35 U.S.C. §119, of U.S. Provisional 
Application No. 60/254,680, entitled "Method And System For Requesting Prices For 
Electronic Trading Of Financial Instruments," filed December 1 1 , 2000, which is incorpo- 
rated herein by reference. 

FIELD OF THE INVENTION 

This invention relates to computerized brokerage systems and, more particularly, to 
the electronic trading of financial instruments via an electronic trading system. 

BACKGROUND 

Market prices for certain types of financial instruments, such as those listed in 
Tables 1A-1C, can change quite significantly in very brief periods of time. However, 
because such instruments are oftentimes thinly traded, on many occasions there may be 
no offers to buy ("bids") or offers to sell ("offers") for a particular financial instrument (also 
called "products" herein). Although traders may be interested in buying and/or selling such 
instruments they may not wish to place bids or offers. Instead, they wish to have other 
traders make bids and/or offers on the particular instrument 

Thus, there exists a need for a method and system which allows traders to jump 
start a market, without exposing the traders to the risk associated with placing bids and/or 
offers. 

F/X Products 
Options 

Vanilla and Currency Pair (USD/JPY, GBP/USD, etc.) 

Calls (European, American, etc.) 

Puts (European, American, etc.) 

Risk Reversals and Straddles (European, American, etc.) 

Strangles (European, American, etc.) 
Exotic and Currency Pair 

Knock-ins/outs (calls, puts, etc.) 
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Reverse knock ins/outs (calls, puts, etc.) 

Forwards 

Currency Pair 

Spot starting 

Forward starting 
Currency Pair (i.e. Spot) Transactions 

TABLE 1A 



Fixed Income Products 
10 Swaps 

Currency (USD, JPY, GBP, etc.) 

Swap spreads (traded with treasury hedge) 
S All-in rate swaps 

2 Spread switches 

JE5 All-in-rate switches 

ffl Basis Swaps 

ip Currency 

S 1-3/3-6/1-6 month basis swaps (LIBOR, TIBOR, etc.) 

J CP-3 month basis swaps (LIBOR, TIBOR, etc.) 

^0 Forward Rate Agreements 

!^ Currency 

1/3/6 month (LIBOR, TIBOR, etc.) 
j; FRA Switches (LIBOR, TIBOR, etc.) 

2 Swaptions 
25 Currency 

European (payer, receiver, straddle, etc.) 

Bermudan (payer, receiver, straddle, etc.) 

Bermudan-European Switches (payer, receiver, straddle, etc.) 

Caps/Floors 
30 Currency 

Cap/Floor, Straddle (LIBOR, TIBOR, etc.) 
Digital Cap/Floor (LIBOR, TIBOR, etc.) 
Convexity Products 
Currency 

35 Cap/Floor, Straddle (CMS/CMT 2, 5, 10, 30 year tenors, etc.) 

Rolling Spread Locks against a spot hedge 
Rolling Spread Locks quoted outright 

TABLE IB 
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Equity Products 
Options 

Vanilla and Underlying (IBM, S&P 500, etc.) 

Calls (European, American, etc.) 

Puts (European, American, etc.) 

Straddles (European, American, etc.) 
Exotic and Underlying 

Calls 

Puts 

Straddles 

Forwards 

Underlying 

Spot starting 

Forward starting 
Underlying (i.e. Stock/index) Transactions 

TABLE 1C 

SUMMARY OF THE INVENTION 

These and other limitations of the prior art are addressed in the present invention 
which is a system and method of electronically trading financial instruments ("instruments"). 
In accordance with one aspect of the invention, requests for proposals ("RFPs") for 
instruments are accepted and broadcast to traders. During a response phase, traders may 
respond to the RFP. Responses are preferably posted to all traders who have responded, 
as well as the requestor. During the response phase, only the requestor may trade on the 
responses. Once the response phase expires, the system preferably enters an action 
phase during which all responders and the requestor may trade on the responses. Once 
the action phase is ended, the open responses are added to the general market. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 A is a schematic of an exemplary computer network implementing the 
invention; 

Figure 1B is an overview flowchart of a process implementing the present invention; 
Figure 2 shows an exemplary market action screen of a trader display with a market 
action table in standard mode; 
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Figure 3 shows an exemplary trader display screen for entering a request for 
proposal; 

Figure 4 siiows an exemplary market action screen of a trader display with a market 
action table In request for proposal mode; 

Figure 5 shows an exemplary trader display screen for responding to a request for 
proposal; 

Figure 6 shows an exemplary market action screen of a trader display showing 
responses to requests for proposals; 

Figure 7 shows an exemplary market action screen of a trader display showing an 
action time for trading on requests for proposals; and 

Figure 8 shows an exemplary market action screen of a trader display showing 
responses which have migrated to the general market. 

DETAILED DESCRIPTION OF THE INVENTION 

With reference to Figures 1 - 8 a preferred embodiment of the invention is 
discussed. Figure 1 A shows an exemplary trading system implementing the present 
invention. A plurality of trader stations 102, 104 and 106 are connected to a financial 
server 100 through a network 1 10. The network 1 10 is preferably a private network 
connected through any number of means, such as T1 lines, digital subscriber lines, cable 
modems, satellite links, or other available connection means. One or more associated 
trader stations 106 may be coupled via a local area network 1 12. A trading system 
administrator station 114 also is preferably coupled to the financial server 100. 
Alternatively, trader stations 102, 104 and 106 may be coupled to server 100 through any 
of a number of means, such as via a public network, such as the Internet, or via a virtual 
private network. The system preferably utilizes a client-server architecture in which the 
trader stations 102, 104 and 106 execute a thin-client written in Java to communicate with 
the financial server 100. In an alternate embodiment, the financial server 100 acts as a 
web server and communicates with trader stations 102, 104 and 106 using a page 
description language, such as HTML or XML. In such an embodiment, traders interact with 
server 100 using a compatible browser (e.g., Netscape Navigator® or Microsoft Internet 
Explorer®). 
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Figure 1B shows an overview flowchart of a process implementing one embodiment 
of the present invention. Figures 2-8 show exemplary user interface screens for trader 
workstations utilized in creating and responding to requests for prices on financial 
instruments. 

5 In one embodiment of the invention, traders are presented with a Market Action 

Screen ("MAS") as shown in Figure 2. The MAS contains a Market Action Table ("MAT") 
100 which shows orders (i.e. bids orders and offer orders) for certain instruments on the 
system. An order has a price, size and instrument (collectively, a "structure") associated 
with it. The MAT 200 can be viewed in different modes in order to view different types of 
m orders. For example, Standard Mode, shown in Figure 2, preferably shows the "inside 
n market" (i.e. the best bid and best offer) for all structures including live orders, ABC orders 
^ (discussed below) and RFP orders; and RFP Table Mode (shown in Figure 4) preferably 
m shows orders for which there is an RFP and also displays the inside market. Each row in 

the MAT 200 represents a different financial instrument. The MAT 200 preferably includes 
Hs a bid column and an offer column which display the "best" bid or offer, respectively, for 
|I each instrument, where "besf is preferably defined in terms of price, but could, in alternate 
:Jr embodiments, be defined by other parameters, such as size or structure of the order. The 
1^ MAS also contains a Market Action Grid 202, which is a graphical representation of 

information in the MAT 200, and a Message Portal 204 which keeps traders abreast of 
20 system activity (e.g. trades, new orders, requests for prices, etc.) by displaying various 
messages. 

Message Portal 204 preferably displays messages which are relevant to the traders' 
positions. In the preferred embodiment, various intensities of messages are available. For 
example, level 1 messages (the lowest level of intensity) are presented in standard text; 

25 level 2 messages (mid-level of intensity) are presented in large text size, e.g. 1.5 x 

standard text size; and level 3 messages (the highest level of intensity) are presented in a 
larger text size, e.g. 2 x standard text size, and may, optionally, be sent twice, the second 
message immediately following the first, and may be accompanied by an audio indication, 
such as a beep sound. Color/blinking indications (e.g. level 1 = green, level 2 = red, level 3 

30 = blinking red) may also be used. Alternatively, use of color may be reserved to indicate 
credit status. Messages may alternatively be sent via e-mail, Internet instant messaging, 
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paging, telephonic (voice notifications and/or voice mails), pager and/or mobile messaging 
systems, such as WAP. 

A preferred interface for creating an RFP order is shown in Figure 3. The trader 
enters the structure he or she is interested in obtaining a price for (the "RFP stmcture") in 
the Structure Sub-Section 304 of the Action Screen 302 shown in Figure 3. The RFP 
structure preferably includes the expiry, tenor and strike price of the instrument. The trader 
also enters the size 312, 314; direction 316, 318 and status 308, 310 of the RFP using the 
Action Sub-Section 306 of Action Screen 302. The size 312, 314 may be below a default 
minimum, depending on the instrument. The direction 316, 318 indicates whether the 
trader wants bids 316, offers 318 or both (a "two-way"). For a two-way, the requested bid 
size and offer size may differ and the requested bid status and offer status may also differ. 
The status 308, 310 indicates whether the trader will accept only Live (i.e. market) orders or 
accept both Active But Confirm ("ABC") and Live orders 308, 310. An ABC order is subject 
to confirmation by the owner of the order before the trade may be finalized. The trader 
clicks the Submit RFP button 320 to enter the RFP into the system. The system then 
checks the RFP and enters it into the system (120 Figure IB). 

In a preferred embodiment of the invention, a trader may enter an RFP for a 
stnjcture, direction and size, even if an RFP for the same structure, direction and size has 
already been entered in the system. Additionally, a trader may enter an RFP for a 
structure, direction and size which already has a standard order placed for the structure, 
direction and size. If there already exists a Live or ABC price for the structure, the system 
preferably warns the requestor that the structure is on the general market and request 
confirmation to submit the RFP. 

Each RFP order is preferably associated with a Response Time (408 Figure 4). This 
is preferably initialized to a system default, but may, alternatively, be user set. After the 
Response Time expires users may not respond to the RFP order. 

As shown in Figure 4, once an RFP order has been generated by a trader, an RFP 
Alert Message 406 is broadcast (122 Figure IB) in Message Portals 204 alerting the 
system users that there has been an RFP. Preferably, the RFP Alert Messages 406 are 
only broadcast to traders whose tradeable structures include the RFP structure (tradeable 
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structures preferably include all structures for which the trader's trading group is authorized 
to trade). 

In one implementation, for each trader (traderx, where x = 1 to n traders), the system 

detennines whether the structure of the action (structureaction) is included in traderx's 

tradeable products. If not, the next trader is evaluated (i.e. x is incremented). If the 

structure is in the trader's tradeable products, then an RFP Alert Message 406 is 

generated. Preferably the RFP Alert Message is assigned intensity level 2 and a message 

string is generated (step 424) as follows: 

"[cause text]:[pre-structure header]][main structure 
header],[Size]MM[Direction][Status]REQUESTED[time]" 

where, 

cause text = "RFP"; 

pre-structure header = 

if the structure of the RFP is not in traderx's open screen group, i.e. if 
the structure is not in the currently open screen, display a pre-structure header., 
(e.g. USD, GBP, USD/JPY); 
else BLANK; 

main structure header = 

<display continuous material attributes of the structure, e.g. the informa- 
tion in the exp/ten and strike columns as shown in market action table 
200 (e.g. 412 of Figure 4)>; 

size = size of the order requested by the owner of the RFP; 
direction = 

"bid," "offer" or "two-way" depending on whether the RFP owner wishes 
to buy or sell the instrument; 

status = 

if RFP owner is willing to accept ABC responses 
then "ABC", else BLANK; and 

time = the time the Alert was generated (preferably right justified). 
If the RFP is a two-way and different sizes or status are requested, the system will 
preferably generate two separate RFP Alert Messages. Alternately, the system simply 
generates two RFP Alert Messages for each two-way RFP. 
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As discussed above, the RFP structure is also preferably indicated 402, 404 in the 
MAT 200 when the MAT 200 is in RFP table mode 414 and the RFP structure is one of the 
types of structures being displayed. The MAT indication 402, 404 initially appears as a 
single line consisting of the structure header (the "RFP structure header") (shown as 412) 
and remaining response time. The RFP table mode 414 shows all RFPs in existence for a 
given product group. The RFP table 414 optionally shows additional lines depending on 
whether or not the trader has responded to the RFP. Preferably, a requestor's MAT 200 
switches into RFP table mode 414 automatically when the trader submits an RFP. The 
requestor may switch back to any desired mode manually. 

System users can respond to the RFP by clicking on the RFP Alert Message 406 in 
the Message Portal 204 or by clicking on the RFP structure 402, 404 in the MAT 200. 
Users must respond within the allotted Response Time (shown as 408 and 410). 

Once a user indicates that they wish to respond to the RFP (such as by clicking the 
RFP Alert Message 406 or RFP structure 402, 404), they are presented with the RFP 
Response Tab 502 of the Action Screen 302 (Figure 5) where they enter a price or prices. 
As shown In Figure 5, the RFP response attributes include direction 504, 506, size 508, 
510 and status 512, 514. Direction 504, 506: must be a bid if the RFP direction 316, 318 
was bid; must be an offer if the RFP direction 316, 318 was offer; and in the preferred 
embodiment can be a bid, an offer or a two-way if the RFP direction 316, 318 was two-way. 
If the embodiment implements a default minimum size, any size not less than a default 
minimum is allowed for responses to non-sub-market size RFPs. If sub-market size RFPs 
are allowed, any size not less than a sub-market RFP size 312, 314 is preferably allowed. 
Preferably, bid size 508 and offer size 510 can differ for responses to two-way RFPs. 
Status 512, 514 must be Live If the RFP status 308, 310 was Live; can be Live or ABC if 
the RFP status 308, 310 was "Live or ABC". Preferably, bid status 512 and offer status 514 
are allowed to differ for responses to two-way RFPs. The trader clicks the submit response 
button 516 to submit the response to the RFP to the system. The system accepts and 
verifies (124 Figure IB) the response. 

Once a response to an RFP is submitted (newly or as an edit), the Responder^s MAT 
200 preferably switches to RFP table mode 414 (Figure 4). The responder may manually 
switch back to any desired mode. 

8 



lCOR-004 PATENT APPLN. 

The system broadcasts RFP responses to the requestor and other responders (126 
Figure 1B). The system preferably also broadcasts the responses to the requestor's and 
responder's trading groups. An example of a set of RFP response orders 602, 604, 606 is 
shown in Figure 6. Preferably, the responses are only visible to the requestor and those 
who responded to the RFP (i.e. they only appear in the MAT's 200 and Message Portals 
204 of the requestor and responders) as well as their trading groups. The RFP responses 
602, 604, 606 appear in the RFP table mode 414 of MAT 200. The RFP responses 
preferably are displayed below the associated RFP structure indicated 402 on MAT 200. 
The MAT 200 preferably shows the full stack of RFP responses (as compared to the "best" 
RFP response). 

As shown in Figure IB, in the preferred embodiment, the RFP process has two 
phases: a Response Phase 140 and an Action Phase 142. The Response Phase 140 
preferably begins as soon as the RFP is submitted. The Response Phase 140 ends when: 
(i) the requestor (or requestor's trading group) trades 131 on any of the responses - 
preferably for any size trade); (ii) the requestor's trading group responds to the requestor's 
own RFP; or (iii) the Response Time 408, 410 expires (130 Figure IB). The Response 
Phase 140 preferably does not end based on a requestor's (or a requestor's trading 
group's) query of an ABC response. The Action Phase 142 begins as soon as the 
Response Phase 140 ends. The Action Phase 142 ends when the Action Time (702 Figure 
7) times out 136. 

During the Response Phase 140 and Action Phase 142, only the responders and the 
requestor see the RFP response orders (602, 604, 606) for a given RFP. As noted above, 
this display may be extended to the responders' and/or requestors' trading groups. 

During the Response Phase 140 only the RFP requestor (or the RFP requestor's 
trading group) can trade on (i.e. hit bids/lift offers). In a preferred embodiment only the 
RFP requestor may query the RFP response orders (128 Figure 1 B). Responses do not 
get matched during the Response Phase 140 and are permitted to cross. During the 
Response Phase 140, traders outside the requestor's trading group are only permitted to 
submit responses to the RFP and edit or pull their responses. In an alternate embodiment, 
the time that users have to respond to the RFP and the time that the requestor has 
exclusive rights to trade on the RFP responses need not be the same. 

9 
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After the Response Phase 140 ends, the Action Phase 142 begins during which both 
requestors and responders (as well as their trading groups) may trade on the RFP 
response orders. In the prefenred embodiment the Action Time (702 Figure 7) is set as a 
system default but in alternate embodiments the requestor is allowed to set the Action 
5 Time. 

When the Action Phase 142 begins, the system first matches 132 any crossed 
responses with agreeable credit limits. If the bid is higher than the offer, the system 
preferably averages the price. In an alternate embodiment, the system will give preference 
to whoever entered the response to RFP first. Thus, the second responder's price (if better 
So than the first responder's price from the first responder's point of view) is used to match the 

0 order. Other methods of determining prices of crossed orders may be used. Once 

1 acceptable crossed orders are matched, all responders to the stmcture, as well as the 

% requestor, and the responders' and requestor's trading groups, are allowed to act, i.e. trade 

1 and query, on open responses with equal priority 1 34. Standard trading rules apply. 
J,^5 Preferably, no new responses to the RFP are allowed during the Action Phase 142. 

2 Once the Action Phase 1 42 ends 1 36, all lines in the RFP table related to the RFP 
I* (e.g. 402, 602, 604 and 606 Figure 6) are removed including the RFP structure header (e.g. 
U 402). The remaining RFP response orclers migrate 138 to the general market and become 

available to be traded on by other system users authorized to trade and/or query the 
20 instruments (shown as 802 in Figure 8). If there already exists a standard mode stack for 
the given RFP stmcture. the RFP responses are placed in the stack based on standard 
parameters, e.g. price, status, last time of edit. If there is no existing stack, the RFP 
responses become standard mode orders for the structure. Sub-market size RFP 
responses preferably become standard orders after the Action Phase 142 ends. 
25 The invention is suited to a variety of financial instruments including those listed in 

Tables 1A - C, as well as stocks and bonds. Moreover, the invention also applies to 
contracts based upon the exchange of any commodity, such as contracts for the exchange 
of bandwidth, real estate, electricity, processing power, freight transportation, etc. Thus, 
the term "financial instalments" as used herein includes contracts based upon such 
30 commodities or services. 



10 



ICOR-004 PATENT APPLN. 

Although the specification and illustrations of the invention contain many particulars, 
these should not be construed as limiting the scope of the invention but as merely providing 
an illustration of the preferred embodiments of the Invention. Thus, the claims should be 
construed as encompassing all features of patentable novelty that reside In the present 
invention, including all features that would be treated as equivalents by those skilled in the 
art. 



11 



